リザーブドインスタンス（RI）に関してこの数ヶ月で多くいただいたお問い合わせを紹介します。〜オペ部だより〜

こんにちは、札幌在住 AWS 事業本部 オペレーション部（通称オペ部）の池田です。オペ部ではクラスメソッドメンバーズにご加入いただいているお客様が直面されたお困りごとや疑問など、様々なお問い合わせに対して各種ドキュメントや技術検証結果のご案内をしたり、場合によっては AWS と連携してお客様が直面している問題解決の支援を行なっています。
本記事では、この数ヶ月で実際に複数のお客様よりいただいた、リザーブドインスタンス（RI）に関するお問い合わせとその回答内容をご紹介します。

全サービス共通

はじめて RI を買います。本番稼働中のインスタンスに対して適用させたいのですが、再起動など何か作業が必要でしょうか。

いいえ、稼働中インスタンスへの作業等は必要ありません。RI は割引の権利を購入するものとお考えください。
ちょうど、chicca がわかりやすい記事を公開していますので、こちらもご参照ください。

リザーブドインスタンスは実際に「インスタンス」を購入していない件について

複数の AWS アカウントを利用しているのですが、間違えたアカウントで RI を買ってしまいました。取り消せますか。

いいえ、購入後の RI はキャンセルができません。

Q. リザーブドインスタンスをキャンセルすることは可能ですか？
A. リザーブドインスタンスのキャンセルおよび前払い分の返金はできません。予めご了承ください。

ご利用中のお客様からのよくあるご質問より

予防策として、購入操作はダブルチェックを行うようにしたり、ログイン時のアカウント ID の指差し確認や、各サービスダッシュボードで稼働中インスタンス一覧を確認するなど、購入画面に移動する前にワンクッション確認作業を挟んでみてください。

EC2

EC2 Classic の RI を購入していましたが、構築をし直す際に VPC 環境に変更しようとしています。購入済みの RI は無駄になるでしょうか。

キャパシティー予約（AZ 指定）の有無によって異なります。
対象の RI がキャパシティー予約（AZ 指定）を行なっていない場合は、問題なく新しいインスタンスに対して割引が適用されます。キャパシティー予約（AZ 指定）を行なっている場合は、購入済み RI と同じ AZ で起動しているインスタンスのみが適用対象となりますので、AZ も変更する場合には注意が必要です。

ネットワークプラットフォームとキャパシティ予約の関係については、下記ブログ記事がわかりやすいです。

【AWS】古参ユーザーほど気をつけてほしいRI購入時の注意点（容量保証について）

RDS

Aurora PostgreSQL の RI を購入したいのですが、クラスター構成としている場合はいくつ購入すれば良いのでしょうか。

稼働中の全ての Aurora PostgreSQL インスタンスに対して RI を購入したい場合には、RDS ダッシュボードにてデータベースの一覧画面でクラスター名の行で「サイズ」の列に表示される「nインスタンス」（下図の場合は 2）、または同一インスタンス（下図の場合、db.r5.4xlarge）の合計台数分を購入してください。
特定のクラスターに対してのみ購入したい場合には、上記いずれかの方法で当該クラスターに属しているインスタンスの数量を確認してください。また、Aurora の RI には「マルチ AZ」という購入オプションはありません。適用させたいインスタンスの台数分購入する必要があります。

RDS で シングル AZ の SQLServer の RI を購入しました。インスタンスをマルチ AZ へ変更した場合はどうなりますか。

RDS の RI にも柔軟性が提供されていますが、 SQLServer は対象外となっています。そのため、マルチ AZ へ変更されますと RI の割引は適用されなくなります。
RDS における柔軟性が提供されている DB エンジンは以下の通りです。

MariaDB
MySQL
Oracle (ライセンス持ち込み)
PostgreSQL

Amazon RDS のリザーブド DB インスタンスより

これらにおいては、DB エンジンとインスタンスファミリーが同じであるシングル AZ の RI による割引をマルチ AZ インスタンスの料金に充当することが可能です。柔軟性についても上記ドキュメントに詳細があります。

Redshift

Redshift をいくつか利用しており、全てのノード分の RI を購入したいと計画しています。ただ、特定のクラスターのみインスタンスサイズを大きいものへ変更する可能性があるのですが、その場合は購入した RI を変更できますか。

いいえ、Redshift の RI は購入後に変更することはできません。また、EC2 RI のような柔軟性も提供されていません。そのため、サイズ変更の可能性があるクラスター分については変更のタイミングまでの前後それぞれの期間にかかるオンデマンド料金がどれくらいになるか、変更前後のどちらで RI を購入する方がトータルコストの削減につながるかを試算されることをお勧めします。

ElastiCache

cache.t2.micro や cache.m3.medium の RI を前払いなしで購入したく料金ページを確認したのですが、記載がなく料金がわかりません。

ElastiCache RI はその世代によって選択できるお支払い方法が異なり、料金ページに記載のないものは提供されていません。t2 や m3 ファミリーなどは旧世代となり「軽度使用」「中度使用」「重度使用」のいずれかを選択する必要があります。また、この場合は前払金のほかに割り引かれた時間単価を支払う必要があります。現行世代である m5 や r5 以降のインスタンスファミリーはスタンダードと呼ばれ、EC2 などと同じ「全前払い」「一部前払い」「前払いなし」の支払いオプションが提供されています。
それぞれの料金はこちらのページから確認することが可能です。

DynamoDB

DynamoDB の RI を検討していますが、これはどういったもので、購入内容はどのように算出するのが良いでしょうか。

DynamoDB には「書き込みキャパシティーユニット（WCU）」と「読み込みキャパシティーユニット（RCU）」が、リザーブドキャパシティーとして提供されています。これらは 100ユニット単位で購入することができ、指定された前払金を支払うことで期間中の時間単価が割り引かれる仕組みです。
今後の利用計画と現在の設定値、利用実態を次のように確認、把握されたうえでの購入をお勧めします。

1: DynamoDBダッシュボード、各テーブルを選択した際に表示される右ペイン「メトリックス」タブで当該テーブルでの読み込みおよび書き込みキャパシティーの状況を確認する。
2: 上記画面にて各テーブルに設定されているプロビジョニング済みユニット数と、消費されたユニット数に乖離がないか、想定されている消費状況であるかという点とスロットルイベントの発生状況を把握する。
3: スロットルイベントが発生していないまたは、許容範囲やリトライで解消できていると判断した場合には、実際に記録されているユニットの消費数に対して、プロビジョニング済みユニット数が適切な値となるよう調整を行ってください（現在の値が適切と判断された場合にはそのままで構いません）。

ここまでで確認したプロビジョニング済みユニット数より、十の位を切り捨てた数量でリザーブドキャパシティーを購入しても大幅な割引によるコスト削減が実現できます。
Auto Scaling を利用する前提であれば、上記とは逆に十の位を切り上げて購入される方法も考えられますが、どちらとするかは組織やプロジェクトの予算方針や想定されている利用計画に依存するものと思います。

Elasticsearch Service

Elasticsearch Service の RI をいくつか購入しようとしたら 1つしか購入できませんでした。

Elasticsearch Service では RI を購入する際に一意の文字列で「予約名」を指定する必要があります。そのため、同一プロジェクトだからと同じ予約名として複数種類の RI を購入することはできませんので、予約名の末尾に通し番号を付与するなどして一意の文字列としてください。

Elemental MediaLive

Elemental MediaLive の予約について教えてください。

Elemental MediaLive では入力処理および出力処理と利用するアドオンに対する予約（リザーブド）が提供されています。それぞれ 1時間当たりの料金がオンデマンドと比較して大幅に割り引かれる仕組みです。
各予約は 1時間の間に実行された処理に対して最大 60分適用され、それを超過した処理に対してはオンデマンド料金が発生します。複数の処理を行う場合はその合計時間を考慮した数量で購入する必要があります。この割引の適用について文章を読んでもイメージしにくいと思いますので、AWS ドキュメント入力予約および出力予約の「入力予約または出力予約が適用される方法」に掲載されている図を参照してください。

おわりに

本記事でご紹介した内容は、非エンジニアと思われる方（購買や経理、契約を担当されている方など）からも多くお問い合わせいただいていますので、お読みいただいた方は是非、社内のそういった方々にも共有いただけますと嬉しいです。
また、本記事で触れなかった点については、もしかすると過去に公開した記事でご紹介しているかもしれません。よかったら読んでみてください。

AWS再入門2018 素朴な疑問 -リザーブドインスタンス – 編

読まなきゃ損($∀$)リザーブドインスタンスのススメ -2019春-